The only thing which is missing now is a compatible libCbc, but I can't find one.

@carrascomj maybe this helps

@EdorianDark Great, that looks very promising! Could this work https://bintray.com/coin-or/download/download_file?file_path=Cbc-refactor-win64-msvc14-mdd.zip ? Or maybe the others here https://bintray.com/coin-or/download/Cbc/

I give up. I have no idea what the difference between all these builds for windows is.

Seems like the ABI should be stdcall on windows, maybe that's the problem?

The remaining problem seems to be to find the remaining Cbc library.
The last build failed with

C:\Cbc\lib\libCbcSolver.lib : warning LNK4272: library machine type 'x86' conflicts with target machine type 'x64'
But there are too many different x64 builds to try to find a fitting one.

https://bintray.com/coin-or/download/download_file?file_path=Cbc-2.10-win64-msvc15-mdd.zip should do the trick. All these msvc builds are because the C++ ABI is different between the different compiler versions. But here we use the C abi, thus all builds should work.

https://bintray.com/coin-or/download/download_file?file_path=Cbc-2.10-win64-msvc15-mdd.zip should do the trick. All these msvc builds are because the C++ ABI is different between the different compiler versions. But here we use the C abi, thus all builds should work.

@TeXitoi That didn't work :(. I tried this fork with the file here. By the way, I also tried without using that file in this CI without any conditional compilation, and it didn't work either.

Hey, that's better!

According to the logs msvc14 is used, so better to use https://bintray.com/coin-or/download/download_file?file_path=Cbc-2.10-win64-msvc14-md.zip

Then, the dependencies need to be also given. Looks like osi-clp cgl osi coinutils are needed. so maybe giving more libs will fix the problem?

@TeXitoi That's all included in the Cbc zip file, so I tried linking everything under lib (that's basically required for those deps). It didn't work.
Checking the cbc.pc

prefix=/c/projects/dist
exec_prefix=${prefix}
libdir=${exec_prefix}/lib
includedir=${prefix}/include/coin

Name: CBC
Description: COIN-OR Branch and Cut
URL: https://projects.coin-or.org/Cbc
Version: 2.10
Libs: -L${libdir} -lCbcSolver -lCbc 
Cflags: -I${includedir}
Requires: osi-clp cgl osi coinutils 

My wild guess is that we are missing the -I C:\Cbc\include\coin, but I am unsure about how to pass that. Would it maybe bindgen be a better option here? (I know bindgen allows for passing clang flags easily).

Hello,

I am currently trying to get this to run in Windows. I got it to work using these steps:

1. I downloaded the statically linked libraries from the coin-or github repo
2. Had to rename libCbcSolver.lib to CbcSolver.lib
3. Include a build.rs file with the following content:

fn main() {
    println!(
        r"cargo:rustc-link-search=<path_to_where_cbc_libs_are>\\lib"
    );
    println!(r"cargo:rustc-link-lib=static=CbcSolver");
    println!(r"cargo:rustc-link-lib=static=libCbc");
    println!(r"cargo:rustc-link-lib=static=libCgl");
    println!(r"cargo:rustc-link-lib=static=libCoinUtils");
    println!(r"cargo:rustc-link-lib=static=libClp");
    println!(r"cargo:rustc-link-lib=static=libOsi");
    println!(r"cargo:rustc-link-lib=static=libOsiClp");
}

4. cargo test runs.

Now: is there somebody still trying this out? Or do the owners here think it might be better to start fresh?

Thank you in advance,

Phil

edit: disregard this as a question because there indeed is a "static" flag. Its in the link attribute as kind="static".

Hi! What the status of using coin_cbc on Windows (not WSL)? I can readily get my cbc install found but, even after having tried many of the cbc releases, I just end up with unresolved exports.

@philsuess stated success using 'the statically linked libs' but I'm not sure how that got things running. According to the docs

The singlethread-cbc feature MUST be activated if this crate is going to be used with a cbc dynamic library ...

So is there a static lib flag or something? I don't know, about now I'm just shooting into the dark...

Any help or info would be appreciated.

@Thell the text you are quoting is not really about a dynamic library, but about a library compiled without thread safety.